组织

http://www.cnblogs.com/aocle/archive/2011/10/10/2205033.html 组织完整介绍+大图 【在企业管理实践的过程中，“组织”（Organization）一词是个经常需用到的概念，一般与“人员”与“职能”这两个要素密切相关，反映某种行政管理关系，例如“财务部、销售部、采购部、生产部、仓储部”等等。企业内部行政组织（部门）的划分是企业基于“职能驱动”业务管理模式进行运作的基础。目前，国内适用于小企业使用的大多数低端管理软件并不考虑系统中的“组织”设置问题，其系统应用模块的划分，例如采购模块、仓管模块、销售模块等等，实际上就已经基本反映了企业运作的“组织职能”划分问题。 但是，对于业务复杂、规模较大的企业（如所谓“集团企业”），管理软件使用与实施的系统“组织设置”问题将是一个首要的重要问题。一个常见的、也是错误的系统实现方式就是将企业的“行政组织设置”直接映射到系统中，以“行政组织”代替“业务组织”。这种系统实现方式虽有理解、掌握比较容易的优势，但却完全违背了大企业运作必须基于“流程驱动”业务模式的基本管理原则。国内有所谓高端管理软件在系统实施过程中，常常出现有几十个财务、采购组织，几百个销售组织，乃至上千个库存组织的“盛况”，导致系统几乎没法使用的困境，其症结正在于此。 与企业的“行政组织”设置与人员规模密切相关且复杂多变不同，软件系统的“组织设置”必须以业务流程运作为核心，要求尽可能简单并保持相对稳定，在公司（人员）规模扩大的过程中具有延续性与继承性。 作为ERP鼻祖的SAP将系统组织简单地分为“集团（Client）、公司代码（Company Code）、采购组织（Purchase Org）、销售组织（Sale Org）、工厂（Plant）”等类别。ORACLE的组织设置本质上与之基本相似，但作为后来者作了进一步抽象与简化，系统组织划分为“业务组（Business Group）、法律实体（Legal Entity）、业务实体（Operating Unit）、库存组织（Inventory Org）”等。 如果说SAP的组织模型字面上多少还带有一点“行政组织”痕迹的话（这可能是某些声称学SAP的国内产品误入歧途的原因），ORACLE系统的组织模型字面上已经几乎看不出与“行政组织”还有什么关系，其中的“Inventory Org”现今中文翻译成“库存组织”，容易令人望文生义和企业的“仓库管理部门（Warehouse）”混淆，但Inventory的本义实际应该是“存货”，称之为“存货组织”或许更好一些。 从企业实际业务管理需要的角度去看，业务组织OU可以看作是在系统中按照业务的相似性，把多个不同公司（包括LE）的业务处理过程及数据划分成相对独立的“管理单元”。在每个管理单元内部，各公司的业务运作共享相关数据并执行统一的业务策略。 在一个业务实体OU下，包含了各地所有负责该事业部的分公司、子公司（LE）的日常业务运作，在业务运作的组织层面忽略了作为法人实体的公司信息，但在反映业务运营最终结果的财务阶段（GL），仍能够方便地按照各地的法规要求提供财务数据与结果。LE的数量可以根据需要任意增加，但对于OU的数量基于管理方便性则要求尽可能精简。 如果说法人实体LE与真实世界的企业行政管理组织架构还有点关系的话，业务实体OU则是与行政管理几乎无关，企业内部的行政组织变化对OU的设置没有直接影响。在EBS中有关采购管理、销售订单履行、应收应付管理等业务模块的功能均是建立在OU基础之上的。用户在执行上述相关模块的业务处理时，总是必须进入确定的OU（上下文环境）才可以进行，EBS的所谓“多组织”功能（MOAC）也是针对多OU而言的，与真实世界中的“多公司”（LE）没有直接关系。 库存组织是位于业务单元的库存计算对象，内涵远不是真实世界的“仓库部门”那么简单，它除了是有关“物料接收与发出”等业务功能的基础之外，更重要的是，它还是EBS系统有关计划（MPS/MRP）、在制品管理（WIP）、物料清单（BOM）等模块业务功能的操作与管理平台。库存组织INV的作用与功能可以与SAP中的工厂Plant参看。一个库存组织INV只能属于一个确定的帐套、一个确定的法人实体LE、一个确定的业务实体OU，具有唯一性的关系（与实际相同，一个具体库存数据不可能属于2个不同的业务实体，否则按业务组织的库存估价将重复）。反之，一个“帐套/法人实体/业务实体”组合则可以有多个库存组织INV。此外，一个OU下的多个INV可以对应属于该OU的不同LE，这相当于将分属于两个法人公司的生产两种产品的四个工厂，按相同产品两两组合抽取出来，分属于两个不同OU进行日常业务管理。 在组织设置界面中，所谓的组织“类型”（Type）划分仅是基于组织自身的统计分析工作需要而定义的一个“维度”，并不影响系统的业务处理功能。真正起作用的是设置界面中的“组织分类”（Classification），各应用模块所具有的业务处理功能通常需构建在一个确定的“组织分类”之上，“组织”是相关业务处理功能的平台，企业是否需要作相关组织分类设置、如何设置，取决于企业所需要使用到的应用模块功能。对于绝大多数基于库存组织INV的业务功能（个别除外），系统用户在做业务操作时，均必须首先进行INV的选择切换，以便进入确定的INV上下文环境。库存组织的作用是如此基础，以至于相关文档在提及组织（Org）概念时，如果未作特别说明，默认就是指INV组织。 对于并不涉及“上下文”环境切换的所谓“组织”，系统的设计主要是为了借用“组织”所具有的“层次结构”（Hierarchy）概念来达到“多组织接入”权限的控制功能。 需指出的是，这里的组织“层次结构”与真实世界企业的行政管理组织层次结构没有直接关系（尽管可能有所参考），它只是企业根据某种需要（如权限管理控制、数据统计汇报等）而人为设定的一个“层次结构”，例如将系统中已经设置的任意数量的“业务实体”或“库存组织”等等组织Name，人为地设定一个具有上下级关系、自顶向下的金字塔形多层结构。】 EBS 通过“MO：业务实体”、“MO：安全性配置文件”、“MO：默认业务实体”这三个系统配置文件的共同作用，实现所谓“多组织接入”控制功能MOAC。但上述三个配置文件在R11与R12中的作用有比较大的差别。 对于“MO：业务实体”， 在R11中必须设定，而且起决定性控制作用，其LOV由系统基于创建的OU name自动创建，用户登录时系统自动定位于指定OU。而在R12中，一旦设定“MO：安全性配置文件”，则此配置文件失效而不起作用。 对于“MO：安全性配置文件”， 在R11中虽有，但实际不起OU接入的控制作用，只针对FA等模块的得某些应用如数据统计等起作用。因此，一般认为R11并不具有完善的多组织接入控制功能。在R12中，该参数如果不设定，则必须设定“MO：业务实体”参数；一旦该参数被设定，则就起决定作用，系统主要依赖其实现MOAC。 对于“MO：默认业务实体”， 在R11中虽有但实际不起作用。在R12中，随“MO：安全配置文件”起作用后才起作用，其LOV是所有已定义OU，但如果设定值不在“MO：安全配置文件”所选择的“组织层次架构”的范围内，则仍不起作用（即在与OU相关诸如PO、OM等的FORM界面，OU字段的默认值仍然为空）。这似乎是ORACLE 系统设计方面的一个难题，即“MO：默认业务实体”的LOV值集无法与“MO：安全性配置文件”中“组织层次架构”中的OU值范围保持一致。 ORACLE强调其“多组织接入MOAC”功能主要是针对业务实体OU而言，其另外一层含义是，所有构建于库存组织INV上的应用功能，实际是与上述配置文件无关的。库存组织的可接入性是在“组织访问”控制功能中，专门设定“库存组织”与“责任”的关联性。 <以上引用oracle大拿的话> 经营单位和库存组织 在Oracle EBS系统中，存在很多组织的概念和分类，经营单位和库存组织在系统中都是属于组织，但它们属于不同的分类，因此所具备的特征和能力也不一样。 经营单位(Operating Unit)是指具备独立会计核算能力的单位实体，Oracle EBS系统中地应收、应付、销售、采购、现金管理和项目会计等模块都在经营单位下进行对立会计核算。 简单的按照通常企业的表现来描述，经营单位可以简单的理解为企业中的一个部门(实际上会有较大的差异) 库存组织(Inventory Organization)是用来跟踪库存业务和余额以及分销商品的一种组织形式。Oracle EBS系统中的库存、物料单、工艺设计、在产品、主生产计划/MRP、能力、质量、成本管理、供应链计划等模块都按库存组织进行安全性控制。 库存组织决定了销售和采购模块可获得的物料信息。库存组织可以简单的理解为是企业中的一个仓库(库存组织可以虚拟) <以上引用oracle大拿aronezhang的话>

Oracle的账务组织架构

Oracle多组织

https://wenku.baidu.com/view/cda13baf58fafab068dc0285.html 多组织架构简介 6种组织类型： 1. 业务组: 它代表组织结构的最高层次, 它分离了人力资源的信息。 例如, 当你查询人员时, 它会列出所有分配给相应业务组的成员, 而你自己所属于的组织只不过是业务组的一份子。 这样说可能造成一种误解: **一个公司只能有一个业务组, 实际上可能有多个, 但是业务组之间不能共享信息**。 2. 帐簿: 它其实不能称为一种组织,更象组织中的一个层次或性。 一个业务组中可以有一个或者多个帐簿。 3. 法律实体: 法律实体类型赋予组织税码以及其它与法律相关的属性。 一套帐簿可以分配给多个法律实体。 4. 平衡实体: 平衡实体就是帐户结构中的一个段, 即平衡段。 在你准备财务报表的时候它体现你的帐户实体。 5. 业务实体: 如果一个组织应用到现金管理, 订单管理, 运输, 应收, 应付和采购模块, 则它就是一个业务实体。 它可能是一个销售中心, 一个分公司,或者一个部门。 对于这些应用, EBS按照法律实体分离了业务信息, 每个用户只能访问到他自己所属于的业务实体的信息。 一个法律实体下面可以有一个或者多个业务实体。 6. 库存组织: 当一个组织要用到库存事物(例如接收, 转移等), 或者它要负责制造和分销产品时, 这个组织就是一个库存组织。 它可能是一个制造厂, 仓库, 分销中心或者销售部门。 当用到下列模块时, EBS按照库存组织来分割业务信息: Oracle Inventory, Bills of Material, Engineering, Work in Process, MasterScheduling/MRP, Capacity, and Purchasing receiving functions。 当你登陆到这些模块时, ORACLE EBS会提示你选择一个库存组织。 同样, 一个业务实体下面可以有一个或者多个库存组织。 特殊组织 1. 人力资源组织: 它体现了一个公司的基本工作结构。 只有当一个组织是人力资源组织时, 你才能分配人员给这个组织。 一个业务组中可以有一个或者多个人力资源组织。 2. 资产组织: 资产组织属性使组织可以执行与资产相关的功能。 只有当一个组织属于资产组织时, 才能使用Oracle Assets。 还需要说明一点的是: EBS的一个组织并非只能归属于一个类型。 例如, 例如, 一个组织是一个业务实体, 若在这个组织中要用到Oracle Inventory, 那么它同时还是一个库存组织。 所以, 组织类型代表了组织的一种属性, 而不是把组织简单的分类。 实施多组织结构 1．规划和描述组织结构。这一步是关键，实施多组织结构能否成功，就在于能否正确描述它，组织结构应该能够描述成如下层次结构： ⑴，业务组 ⑵，会计帐簿 ⑶，法律实体 ⑷，业务实体 ⑸，库存组织 2．定义会计帐簿：这一步使用GENERAL LEDGER职责实现。会计科目弹性域，币种，会计日历是定义会计帐簿的三要素。因此，本步骤假定这些已经完成。 3． 定义地点：每一个组织总是对应于一个地点，也可能多个组织使用同一个地点。ORACLEEBS使用地点来实现采购申请，接收，运输清单和人员分配。 4．定义业务组：系统中必须至少有一个业务组。 你可以根据需要创建新的业务组。 若不需要用到多个业务组, 则你可以使用系统中预定义的业务组, 通过部分修改来满足你的要求。 若你创建了一个新的业务组, 则你需要在职责层修改参数才能访问新的业务组。 在你创建了一个新的业务组之后, ORACLE HR自动创建一个以新业务组名字命名的安全参数值。 你必须在创建其它任何类型的组织之前定义好你所有的业务组, 因为业务组会隔离包括组织结构在内的所有业务信息, 你如, 你在一个业务组定义的人员信息, 任何其他的业务组都不可能访问。

多组织权限控制

多组织架构实现了经营单位(OU)的数据安全性，在底层数据表中有一列ORG_ID来记录数据所属的经营单位，所有多OU的基表都是以”_ALL”结尾，对应经营单位屏蔽信息的视图创建在APPS数据库模式下。 多OU的视图通过职责上面设置的MO: Operating Unit预制文件的值来限制值的读取。预制文件的值在用户登录系统职责后通过FND来初始化，CLIENT_INFO这个功能函数来取得ORG_ID的值，这个值在一个连接会话中有效。这样一来一个职责只能访问一个经营单位的数据。 从Oracle Applications R12开始，使用了多组织访问控制(Multi-Org Access Control)功能，使用户在一个职责下存取一个或者多个经营单位(Operation Units)的数据。增加了用户操作的方便性和灵活性。MOAC是通过安全配置文件(Security Profile)来实现的，通过在HR模块中定义安全配置文件来包括层次结构的组织架构，然后使用MO: Security Profile 预制文件将安全性配置文件和职责关联起来，这样就实现了用户能够访问MO: Security Profile预制文件中所对应安全配置文件中的经营单位信息。而后台则是通过数据库中的VPD(Virtual Private Database)功能来替换CLIENT_INFO实现多OU存取数据的控制。 MOAC对用户系统操作的影响 : 所有与多OU相关的业务窗口中，都添加了一个OU选择的值列表 MOAC对客户化开发的影响: VPD(Virtual Private Database)替换了CLIENT_INFO，因此以前的安全性访问初始化的方式已经不再适用，如R12前使用如下的代码： begin dbms_application_info.set_client_info(‘&org_id’); end; / select * from po_headers / 但是在R12种已经不适用，在12版的工作流数据库包开发中使用MO_GLOBAL来实现 而在表单和报表的客户化开发中，都需要通过安全配置文件来初始化安全访问。 为了和系统标准功能保持一致以及程序的扩展性，需要在多OU相关的界面设计中添加OU选择的值列表。 关于R12的新特性Multi-Org Access Control(MOAC).Oracle宣传的好处主要有: 1. enable users to access to secured data in one or more Operating Units from a single responsibility 使用户能够从一个单一的责任访问一个或多个经营单位的安全数据。 2. End-Users can access/transact data within several operating units based on Security Profile attached to a responsibility. 最终用户可以基于安全配置文件连接到责任访问/办理多个经营单位内的数据。 3. Profile 'MO:Security Profile' will ensure access to multiple operating units from single responsibility Profile 'MO:Security Profile'可以确保从单一的责任访问多个经营单位 具体为什么会改成这样的原因可以从R12的宣传语看出:"The Global Business Release" "R12 Enables You To Think Globally,Work Globally,Manage Systems Globally " 从技术角度的一些拾零记录 1. 在R12之前的版本中,组织控制是通过View来实现,比如说AP_INVOICES是定义在AP_INVOICES_ALL上面的View,而View一般都是通过在ORG_ID加条件来限制数据访问. 从R12开始,这样的View被取消了,取而代之的是同义词(synonyms),比如说AP_INVOICES就是AP_INVOICES_ALL的同义词(synonyms). 在R12里可以通过下面的SQL语句来查询有这样关系的表 select * from dba_synonyms syn where syn.synonym_name || '_ALL' = syn.table_name 2. R12中的组织访问限制是如何实现的呢? 是通过数据库安全方面的新特性virtual private database (VPD) policy来实现的,具体就是给_ALL表的同义词(比如说AP_INVOICES),添加对应的Policy. 这样在在查询的时候,数据库会根据Policy的来生成对应的条件(where)语句,来限制我们对数据的访问. 通过select * from dba_policies where policy_name = 'ORG_SEC'我们可以查询到那些表添加了Policy,以及是通过那个具体的Function来生成要添加的where条件 我们通过查询可以发现,比较具体的一个例子 Policy_name: ORG_SEC Policy_group: SYS_DEFAULT Package: MO_GLOBAL Function: ORG_SECURITY 通过查看MO_GLOBAL.MO_GLOBAL,我们可以看到具体的生成限制语句的逻辑.其中Multiple OU Access是通过GLOBAL TEMPORARY TABLE MO_GLOB_ORG_ACCESS_TMP来实现的. 可以参看Note462383.1来看具体的每种情况会生成什么样的Where条件(a WHERE clause). 3. 可以通过表FND_MO_PRODUCT_INIT中的STATUS来判断具体的某个Application是否支持MOAC. 4. 通过表FND_MO_SP_PREFERENCES的User_ID, Resp_ID, Security_Profile_ID可以查看缺省的组织(Default Org_ID).相关联的Profile是MO: Default OU 参考：http://snans.blog.51cto.com/3262503/1352377/ 多组织数据过滤

子帐SLA

5.1 子帐的概念——SLA（SubledgerAccounting） 概念：子帐是子分类帐会计的简称，字面上的含义就是子分类帐会计分录，但是这东西到底用来干吗的呢？！ 通俗的说： 1、子分类帐会计其实就是连接子模块会计和GL凭证之间的桥梁，更简单的说，就是子模块和GL之间的桥梁。所有子模块（包括FA）产生的会计分录都是使用SLA产生的，存放在SLA的表中，然后通过过帐程序过帐到GL。有点类gl_interface表的功能。 2、子分类帐会计的第二层意思：在各个子模块都有一套独立的会计分录，看起来跟GL其实没太大区别，这就意味着在子模块其实就可以计算科目余额了。只是可惜，到目前为止我还没有类似gl_balance的表来存放科目余额。 3、 各子模块目前还是可以有自己的分配帐户（就是以前查看会计科目看到的东西），分别存放在自己的分配表中，比如，AP还是存放在ap_invoices_distributions中，引入SLA后，把这个功能称为“事物处理会计”，和子分类帐会计的不同点在于，事物处理会计是通 过自动会计或分配产生，而子分类帐会计是根据定义会计事件等公式产生的，分别存于不同的地方。 子帐架构 解释： 1、 子分类帐的产生有两种方式，一种方式是直接从子模块的事物处理会计，一种是直接从子模块的事物处理上取得。 2、 子模块的事物处理会计和子分类帐会计是两个不同的东西，一定要区别对待，传送到GL的是子分类帐会计，并非事物处理会计。 3、 由于子分类帐会计的来源可能是事物处理，也可能是事物处理会计，因此很可能存在差异，这是SLA目前的缺陷。 子分类帐带来的益处 1、 灵活的定义会计分录的产生规则，包括摘要，借方和贷方 2、 一个事物处理可以过帐到多个ledger(就是11i的帐簿)，这给跨国集团管理多个帐簿带来很大的好处 3、 统一了子模块会计分录的存放和产生规则，也就是说，各个子模块都可以根据自身的情况设置会计规则，但是这些规则产生的会计分录都回存放在SLA的表中。 4、 利于扩展，ORACLE委托外包的子模块产生的会计分录更容易集成到EBS 5.2 SLA的几个重要关键词 SLA 的关键词有很多，不过和我们写程序密切相关的应该是下面几个关键词。这几个关键词是我们弄清楚子模块和GL之间的关键。如果理解了这几关键词在SLA中的 具体位置以及作用，加上SLA的的架构图，很容易的就理解了SLA作为子模块和GL的桥梁作用，对过帐程序具有深刻的理解，便于我们以后编写追溯程序以及 追溯报表。 ● 会计事件(accountevent) 会计事件，就是一个事物处理的不同事件类型产生的记录，它结合了主要分类帐，事件类 型，事件分类。一个事物处理可能会有多个会计时间，因为一个事物处理可能发生多种动作，而每个动作都需要产生相应的会计凭证。因此，我们可以把一个会计事 件看成是一张完整的凭证，我们把这张凭证录入到子模块的会计分录表里就形成了完整的会计分录。所以，我对会计事件的理解通俗归纳为以下几点： 1、 会计事件就相当于一张凭证，录入到GL就是一对会计分录 2、 同一个事物处理，比如收款可能会对应多个会计事件，因为收款创建会产生会计事件，收款核销也是一个会计事件。 查看路径：子模块超级用户/查询/会计事件 ● 主要分类帐(leadger) 分类帐的概念在12i中表示的是帐簿，也就是11i的SOB，主要分类帐决定了过帐到哪个SOB ● 事件实体（EVENTENTITY） 事 件实体决定了会计分录来源，以应收为例子，事件实体决定了到底是从 “应收事物处理”过来的还是从“收款”过来的。存放在表：xla_entity_types_vl中，会计分录和事物处理关联的表是是xla_transaction_entities ,事件实体同时定义了关联的标识是哪个字段，存放在xla_entity_id_mappings，下面我会详细介绍怎么做关联。 设置路径路径：子模块超级用户/设置/会计/子分类帐会计/事件/事件模型 ● 事件分类(EVENTCLASS) 事件分类是根据事件实体进一步区分会计分录的方法。比如，收款分为“收款”和“杂项收款”，事件分类的表为：xla_event_classes_v，属于xla_transaction_entities的子表。 设置路径路径：子模块超级用户/设置/会计/子分类帐会计/事件/事件模型 ● 事件类型(EVENTTYPE) 事件类型是比事件分类更小的事件划分方法，每个事件分类会细分成多个事件类型。比如：收款会分成：收款已核销，收款未核销，收款已更新等等类型。存放在表：xla_event_types_vl中。 设置路径路径：子模块超级用户/设置/会计/子分类帐会计/事件/事件模型 5.3 SLA&GL关系模型 关联模型中，实际参与的表很多，我们只拿最重要的表来描述，以便大家入门，不至于摸不着头脑，力求简单。 ● 基础事件关系图 xla_entity_types_vl（事件实体） ｜――xla_entity_id_mappings（实体ID对应表） ｜――xla_event_classes_v（事件分类） 　　　｜――xla_event_types_vl（事件类型） ● 子分类帐关系图 xla_transaction_entities(会计事物处理实体) ｜――xla_events（会计事件） ｜――xla_ae_headers（子帐头） 　　　｜――xla_ae_lines（子帐行） 　　　｜――xla_distribution_links（关联事物处理信息） ● 子模块和ＧＬ关系图 gl_import_references（总帐参考） 　　｜(gl_sl_link_id,gl_sl_link_table) xla_ae_lines（子帐行） 说明：GL和子模块之间的关联是通过gl_import_reference实现的，关键字段是gl_sl_link_id,gl_sl_link_table。